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SECTION 1 - INTRODUCTION 


This Executive Summary is based on a study conducted by Computer Sciences Corporation 
(CSC) for the National Aeronautics and Space Administration (NASA), Manned Spacecraft 
Center (MSC), to investigate the requirements of a data management system to meet the 
needs of MSC in mission planning and program and resource management during the 1975 
time frame. The study addresses overall system requirements, implementation consid- 
erations, and cost/benefit comparisons. During the course of this study, CSC has exam- 
ined the tj'pes of data that MSC must automate to make available both management and 
technical information in support of the MSC’s functions and missions. Also, software and 
hardware capabilities which can best handle the storage and retrieval of this data have 
been analyzed. 

As MSC's requirements for new types of high volume data continue to grow and the need 
to I'eview and manipulate this data on a "more data faster" basis increases, it is evident 
that although a great deal of computing power exists, a number of necessary applications 
have not been automated, and others are less efficient than desired. 

A properly implemented Data Management Supervisor (DMS) would permit the user to 
quickly describe and construct a data base, query the data base for specific information, 
display the data on a Cathode Ray Tube (CRT), obtain hard copy reports, and update and 
maintain the data base. All of these functions could be performed in either a production . 
basis or interactively from a terminal in an on-line time-sharing mode. 

Of critical importance to MSC will be the proper structuring of data sets to reflect the re- 
quired data to serve both management and line users. This necessitates a sophisticated 
approach to file structuring to meet requirements and control data set volumes. File 
analysis, data content, and file structuring require software systems capable of efficiently 
managing large complex data bases and personnel who are knowledgeable of the critical 
importance of data structuring. 

Greater throughput per computer dollar will result from the installation of a DMS. Such 
areas as increased programmer productivity, greater standardization, reduced program 
development time, and accessibility of data all tend to substantiate the position that in- 
stallation of an effective DMS is cost effective. 
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SECTION 2 - PILOT STUDY ACCOMPLISHMENTS 


In order to propeiTj'^ manage a complex set of missions such as those in the integrated 
manned space flight plan, availability of extensive technical and management information 
will be required. It is essential that this data be current and easily accessible to both 
project management and technical personnel for pre-mission planning, mission support, 
and post-flight analysis. Because of the relatively large number of vehicles and frequent 
flights envisioned for future programs, an automated information management system 
will be necessary. Such automation can effect a more efficient operation and result in 
reduction of costs in the areas of program management, mission planning, and support 
operations. It was necessary to conduct a study to determine the types of data that re- 
quire automation and to determine the system that can best handle the storage and re- 
trieval of this information. 

The first step in the study was to conduct personal interviews with MSC personnel. These 
interviews acquainted the various MSC groups with the goals and purposes of the study and 
identified the data processing needs of the various groups. These interviews also provided 
opportunities to discuss with these users the capabilities of a DMS. An analysis of MSC 
data and information requirements was then performed based on the information obtained. 

A list of currently operational DMS's that wex’e available at no cost to MSC was given to 
the implementing contractor on August 10, 1970. This list of candidate systems contained 
three actual DMS systems and three textual data processor systems. 

MSC established user requirements as the prime consideration in the selection of the pilot 
DMS. Other major considerations included cost, compatibility with other system hardware, 
and terminal capabilities. Trade-offs were made to approach a degree of satisfaction of 
all requirements. These trade-offs generally considered expediency of implementation of 
^ the DMS. As a result of these trade-offs, the NIPS and HYPERTEXT systems were selec- 
ted by MSC to be used in the pilot study. 

2.1 SUMMARY OF INTERVIEWS 

During the data base requirements study project, CSC contacted more than 200 users 
throughout MSC to inform them of the data base requirements study and to determine 
their interest in participating in the stud3^ Through the use of personal discussions in 
a structured interview with each potential user, it was possible to determine the data in- 
terests and software requirements necessary to support both the pilot system and a future 
expanded operational system. 

On November 2, 1970, the implementing contractor presented to MSC the results of its 
analysis of various candidate systems in the document "Progi'am Evaluation Report. " 

Based on the implementing contractor's recommendations, MSC selected the NIPS and 
HYPERTEXT systems to comprise the pilot DMS. 

CSC performed an analysis and evaluation of the pilot DMS systems. A preliminary anal- 
ysis occurred prior to the actual implementation of the systems and consisted of an in- 
depth study of all available documentation on the two systems. A detailed, hands-on 
checkout of all the operational functions supported by the DMS's was then performed. The 
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objectives were to develop proficiency in operating the systems and to discover any idio- 
syncrasies of the systems that had not been uncovered during the documentation study. 

2.2 PILOT D MS DATA 

The following MSC user application data files were structured into the pilot DMS data base: 

0 Labor Distribution 

© Accounting 

0 Procurement 497 

o RMD 

0 Contract Status Report 

© Budgetary Control 

e Capitalized Equipment 

© Engineering Standards Information 

© Earth Resources Text and Table Files 

0 Flight Control Manpower Status 

® Skylab Program Operational Data Book 

o Statements of Work 

The Skylab Program Operational Data Book and Statements of Work files were implemented 
for utilization by HYPERTEXT. All other files were implemented under NIPS. 

2.3 PILOT DMS DEMONSTRATIONS 

Utilizing past experience in the management and technical data areas, CSC designed demon- 
strations of the NIPS and HYPERTEXT systems to show MSG managers some of the capa- 
bilities offered by a DMS. Actual MSC data was used to prepare program queries for a 
representative cross-section of MSC activities to provide demonstrations which were mean- 
ingful to the viewers and to help them relate their data requirements to a DMS. 

The demonstrations showed how data could be retrieved from the data base, sorted, up- 
dated, and displayed to a user. Most groups which viewed the demonstrations expressed 
a desire for a Center-wide DMS at MSC because of the apparent benefits available to them 
in such a system. 

2.4 CONCLUSIONS 

During the conduct of the study several conclusions became apparent. First of all, the 
availability of data to the users on a timely basis was of prime importance. This require- 
ment presented itself in a number of different forms. Timeliness, availability, and the 
capability to selectively and randomly review data was high in each user's consideration. 

Also, a large number of users are developing or considering independent solutions to this 
problem because of the lack of an integrated data base management system at MSC. Firm 
procedures will be required to prevent a proliferation of independent systems involving 
inefficiency and duplication of effort. 

Finally, the pilot DMS was effective in demonstrating that most of these information and 
data problems can be solved by an effective DMS. As a result of the interviews and demon- 
strations, a comprehensive list of required capabilities necessary to support users and 
desirable capabilities to further enhance retrieval and display effectiveness has been 
compiled. 
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SECTION 3 - SYSTEM REQUIREMENTS 


Two categories of capabilities have been defined to support the manj' users' requirements 
that were identified during the course of the study. First, required capabilities are those 
functions that are necessary to support the user by ci'eating a data base, maintaining the 
data base, and providing optional methods for processing and retrieving information. 
Second, desirable capabilities are additional functions which further enhance the practi- 
cality of the total system by orienting it more to the individual user and the solution of 
his problems. 

Both categories of capabilities were derived through the process of interviewing a cross- 
section of MSC users and then demonstrating the effects of these capabilities to them on 
the pilot system. 

3. 1 REQUIRED DMS FUNCTIONAL CAPABILITIES 

Thei'e are ceiTain basic capabilities which must be provided by the DMS. The following 
paragraphs describe those features which are considered essential to successful operation 
of such a system at MSC. 

o Terminal and Patch Processing . A DMS provides both batch and terminal 
processing capabilities. Applications which do not require instant response 
or which process a large amount of input data are executed in the batch mode. 
Applications which require quick answers are done using queries in the ter- 
minal mode. 

© Data Base Description . A means for describing the data in the data base is 
provided by a data description language. The language describes such things 
as field name, field length, record key, record length, file name, file struc- 
ture type, data security, data type, etc. 

o Data Access Security . Everj' file requires "write" protection which restricts 
the capability to add data or modify data to those persons authorized to alter 
the data. Some data must be provided retrieval or "read" protection. Three 
levels of security will be provided, i. e. , field, record, and file. Security 
codes will be assigned to people authorized to access the data. 

© Data Base Creation and Maintenance . The DMS must provide the capability to 
accept user files from various types of input devices (cards, magnetic tape, 
disk, etc. ) and create data files according to the data base description. Sev- 
eral structural forms must be made available including sequential, indexed 
sequential, hierarchical indexed sequential, etc. 

® Process Many Types of Data . Of critical importance to MSC is the structur- 
ing of data to minimize redundancy and reflect the required data to serve man- 
agement, administrative, and technical users. The fe’lowing blocks of data 
comprise the primarj^ types that must be processed. 

Management Data - This type of data relates primarily to the resources man- 
agement area. It will include such items as accounting data, payroll informa- 
tion, personnel data, procurement data, logistics data, scheduling and planning 
data, etc. 
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Technical Data - This data is scientific in nature, i. e. , used in engineering 
calculations or used to describe technical data. 

Library Data - This data is generally descriptive in nature, containing a brief 
amount of information about some larger item. The purpose of this data is to 
show a user identifying information available on a particular item. 

Textual Data - This is documentary data. A document could be entered in 
free form, into a data file and then recalled to be edited and formatted at a 
CRT tei'minal. 

e Simple Terminal Language with Prompting . The language provided by the 
DMS for users at a CRT terminal must be easy to learn and of a semantic 
form familiar to most users. It must prompt the user by asking questions 
and directing the sequence of entries as a user develops a query. 

e Short Terminal Response Time . The primary reason for a DMS and a data 
base is to provide MSC managers quick, direct access to the data w'hich per- 
tains to their operation. This makes the computer more useful as a tool for 
decision making. 

0 Update Data at a Terminal . A DMS must provide update capabilities in both 
the batch and terminal modes. The batch mode will normally be used for 
large volume updates, and the terminal mode for small volume updates. 

0 Queries Using Multiple Search Criteria . The multiple search criteria capa- 
bility enables a terminal user to enter many different search conditions in one 
query. Quick retrieval of specific data is thus provided. There should be no 
limit on the number of search conditions that a user could state in one query. 
Boolean connectors (and, or, not) would be used to connect the search conditions. 

@ Terminal User Selection of Displayed Data . A DMS must provide the capabil- 
ity for terminal users to display any data field in the data base. The users 
must not be limited in the data they can view, except for securit}^ limitations. 

In addition, variable output report format should be provided such that a user 
need not be concerned about formatting the data that is to be displayed. 

© Simultaneous Queries of the Same Data . The DMS must provide capabilities 
for simultaneous queries of the same data by users at different terminals. 

© Keyword Search of Data . This feature allows a user to enter a keyword at the 
console and to retrieve all the information in a file which related to that key- 
word. The keyword may be a subject, author, mission number, site number, 
etc. Capability to use combinations of keywords for search criteria should 
also be provided. 

• Hard Copy of Terminal Displays . Terminal users will need the capability to 

obtain a printed copy of the contents of a CRT display. Hard copies are needed 
so users can take viewed results back to their desks for analysis, thus releas- 
ing terminals for other users. 
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Terminal Arithmetic Operations . Data in areas such as payroll, accounting, 
logistics, and procurement require the arithmetic operations add, subtract, 
multiply, and divide. Internal decimal point alignment (floating point arith- 
metic) must be included with these operations. 

Sort and Merge . The DMS must provide capability to rearrange data that has 
been retrieved from the data base into a new sequence as I'equested by a tei’- 
minal user. The merge routine should be able to combine two or more data 
files according to a user specified sequence. 

o Data Name Synonyms . Some data items are called by different names among 
the various MSC groups. By means of synonyms, different users can query 
an item of data using the name familiar to them. 

© Inter- File Data Query and Update . The DMS must provide a user with the ca- 
pability to obtain data from many different files with the same query. If it is 
necessary for a data item to appear in more than one file, an update of this 
item should automatically update the item in all files in which it appears. 

o Audit Trail of Data Updates . An audit trail is a record of the update actions 
performed on data in the data base. The DMS must provide the capability to 
keep a record of all changes made to a data file. If the data base is destroyed, 
the data base may be recreated using the latest backup tape. Audit trail (s) 
containing the update actions recorded since this backup tape may then be re- 
entered in the data base. 

© Create, Save, and Reuse Terminal Queries . Since the terminal language will 
be a simple, English type language, nontechnical users will be able to create 
their own queries. If a user determines that he will be entering the same 
query repeatedly, the DMS will provide the capability to save such queries. 

o Temporary Saving of Answer Sets . The DMS should provide capabilities to 
store a response to a query and allow that answer set to be recalled as input 
for a suiasequent query. 

o Purge of Obsolete Data . The DMS will provide routines to reorganize indi- 
vidual data files within the data base and delete all records that have been 
flagged as obsolete. 

© Editing and Validating of Data . V\dien new data is added to the database, the 
DMS will provide a validity check and permit data to be entered into the data 
base only when certain validation criteria are met. 

® DMS Error Recovery Without Aborting . Errors can occur during processing 
which will cause system failures. If this happens, control should be returned 
to the DMS, not to the operating system. 

« Easy to Modify and Expand DMS . The DMS will be written in modules in order 
that modifications to one functional area will not impact other areas. 

The DMS should be written in a machine independent language. This will facil- 
itate conversion or modifications when coinputer hardware is changed or upgraded. 
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3.2 DESIRABLE DMS FUNCTIONAL CAPABILITIES 

For reasons of greater processing efficiency and flexibilitj' to the user, it is highly desir- 
aJjle to include certain capabilities. Although these capabilities are not mandatorj'^ to sys- 
tem operation, the increased user effectiveness which they provide is of great value. 

& Variable Length Data Fields . At present, items such as addresses, names, 
remarks, etc. , are limited to specific lengths and in many cases the data has 
to be abbreviated. Conversely, much storage space is wasted by comments 
and textual data that does not fill the space allocated for it. 

0 Textual Document Editing and Formatting . This capability allows unedited 

documents to be input into the data base. The user then edits and formats the 
documents at a terminal to prepare them for printing. 

© Terminal Graphics . The graphics capability allows a user to create drawings 
and objects on the CRT using diagonal lines and points, to display graphs of 
statistical information, etc. 

© Remote Job Entry . This capability allows a terminal user to call up and ex- 
ecute a job stored in a system library. A job may consist of one or more pro- 
grams designed to perform specific tasks. 

o Geographic Type Data . Earth resources at present is utilizing the GEOREF 
system but will eventually change over to the UTM system to malce earth re- 
sources data compatible with outside users in the way they define the coor- 
dinates of the area for which the data applies. 

o Access Data Using Different Languages . COBOL and FORTRAN are the basic 
languages utilized by MSC; therefore, the DMS should include the capability to 
write programs in these languages. 

® Statistical Analysis of Data . Statistical analysis will be tied in very closelj^ to 
the graphics capability. Statistical anal3^sis routines should be callable bj' the 
DMS to provide this capability. 

© Conditional Processing . This capability allows a DMS to initiate or bypass 
tasks or jobs based upon conditions encountered during processing. 

• Automatic Scheduling of Processing . Most of MSC's computer activity will 
be programmed into a "scheduler" module and added to the DMS. The MSC 
applications will then be automatically processed by the DMS according to the 
scheduling criteria specified for each application. 

® Validate Data Base Integrity . The data base will be audited periodically to 

ensure validity of data. The audit will check data items against edit criteria 
such as size or range limitations and type of data (alphabetic or numeric). 

If a data item is deiDendent on other data items, a check could be made to 
ensure the item meets all conditions imposed upon it by the other items. 

® Lockout During Data Update . Once an ipxiate command against an item of 
data has been issued to the DMS, all queries and other processing requiring 
this data will be delayed until the update has been completed. This should be 




at the record level, thus allowing other users to query all records in the data 
set which are not in the process of being updated. 

© Computer Transferability of the DMS . If the major portions of the DMS are 

written in a language which is virtuall 5 ' machine independent (such as COBOL), 
the effort to rewrite them will be gi'eatly reduced if it becomes necessary to 
transfer the DMS to new computer hardware. 

o Inverted Data Files . Inverted files essentially consist of a series of different 
sort key index sets for any data file. Each sort key index set contains records 
in a specific sequence and application data record address pointers. In a 
query, a user will specif 3 ^ the sort key index set which will give him the most 
direct access to his data. 

3.3 REQUIRED HARDWARE FOR THE DMS 

Only nominal special hardware and configuration changes over and above those v/hieh al- 
ready exist at MSC are required to support a DMS. However, in some areas, such as 
direct access storage devices, it will be necessary to increase capacity as data files are 
added. 

© Local and Remote Terminals . The DMS hardware must provide for both remote 
and local terminal processing. Remote terminal processing requires the use of 
common carrier lines between the terminal and the computer processing unit. 
Local terminals normally utilize hard wiring (direct connection) from the com- 
puter to the terminal display control unit. Local terminals, however, should 
also be able to optionallj' utilize modems instead of the hard wiring. In fact, 
it is recommended that whenever possible, modems be widely used for local 
terminals, especially where a terminal location is likely to be changed. This 
method of data communications provides significant flexibility for placement 
and relocation of terminals without the necessity of considerable data line, 
adapter, and control unit hai'dware replacements or modifications. 

There must be interactive terminal consoles which allow users to-specify their 
processing requirements. There should be a terminal keyboard/CRT with al- 
phanumeric characters and a hard copy device that can produce a printed copy 
of the entire generated results of a querj' or the contents of a single CRT dis- 
play screen. 

® Large Core Storage Capacity . Many of the applications at MSC are extremelj'^ 
large, and some application data areas, such as earth resources, will grow to 
huge proportions through the Sltylab and Space Shuttle programs. Queries of 
these data files could ci’eate very large answer sets. Enough core storage 
must be available to handle such queries and at the same time allow other 
programs or jobs to execute (multi-programming capability). 

® Direct Access Storage Devices . The large volume of current MSC applications 
data plus the probable increase in size of some applications data necessitates 
a large random access storage capacity. It is also necessary that a DMS pro- 
vide for many types of data structures. The most important types are indexed 
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sequential and hierarchical sequential. These methods allow for direct access 
to specific data items and the chaining together of like items. 

3.4 DESIRABLE HARDWARE FOR THE DMS 

To make full use of expanded capabilities of the DMS, certain options should be considered. 
Through the use of additional hardware capabilities, greater efficiency and utilization may 
be obtained. 

© Terminal Console Special Features . An auxiliary functional keyboard will be 
provided for text data editing and formatting operations. Once a document has 
been entered into the system, the functional keyboard allows a user to edit the 
document and prepare it for printing. 

The light pen provides a terminal user the capability to identify specific loca- 
tions on the CRT screen at which some operations are to talce place. Vector 
generation capability is also necessary for graphics displays at terminals. 

© Tei-minal Input/Output Devices . There are many printers available today 
which may be installed as hard copy devices at terminals. Magnetic tapes 
may be used as auxiliary storage devices and as backup storage devices for 
the DMS. 

If a MSC group keypunches their own data, it will facilitate their operation to 
have a card reader/cax'd punch at their terminal for remote entry of their data. 
Teletypes may be used as a hard copy device and also as a terminal entry de- 
vice when a more sophisticated device is not economicallj^ justified. 

© Microfilm . Mici’ofilm conserves storage and greatly reduces processing costs. 
Microfilm is now being widely used by MSC in many areas such as earth re- 
sources and engineering plant drawings. Further use of microfilm could reduce 
MSC's cost in the storage and I'etrieval of charts, drawings, photographs, and 
text data documents. 

3.5 DATA REQUIREMENTS 

The broad spectrum of activities at MSC makes it a very complex facility. The DMS must 
be powerful enough to serve the data needs of all areas of MSC. As stated previously, a 
logically and efficiently structured data base is a critical part of the system. The data 
base must contain all data needed by management and technical users. 

® Management Data . The data needed by managers to plan activities, to sched- 
ule work loads, to perform project analysis, and to financially control their 
phase of the MSC operations must be readily accessible and must also be pre- 
sented simply and coherently. 

© Static and Dynamic Characteristics of MSC Data . Most of the currently active 
files in the management area were originally designed and created for the 
Gemini and Apollo programs and will be used for future programs. Most of 
the files in the technical area that will be contained in the MSC data base are 
static, but there are some d 3 mamic files (number of records on the file in- 
creases constantly). Lunar samples is the largest dynamic file in the tech- 
nical area. It will continue to grow as more and more tests are made on the 
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moon rocks. Flight scheduling is also a very active file. Its size varies de- 
pending on mission requirements. 

e Impact of Space Station and Space Shuttle on Data Volume Through 1975 . The 
requirements for resources management will not increase appreciably because 
of new programs such as the Space Station and Space Shuttle. Earth resoiu'ces 
data, however, is cumulative. The library data will be somewhat dynamic, 
too, since more papers, documents, and literature will be published as a rer- 
suit of these programs. 

Data for the scheduling of flight activities for the Skylab and Space Shuttle 
missions will also be in the MSC database. This technical data will have a 
high level of activity, and the volume will fluctuate significantly depending on 
the number and complexity of the flight activities during Slcylab and Space 
Shuttle missions. There will also be a large amount of raw telemetry data 
and engineering data from the Skylab and Space Shuttle missions. Only con- 
densed summaries of this data need be considered for implementation into 
the Center-wide data base. 

© Data Adaptable to Data Base Type Operations . The DMS and Center-wide data 
base are management tools to be used as aids in decision malting. The general 
guideline for implementing data into the Center-wide data base is to structure 
that data most needed by MSC managers to aid them in decision malting and 
planning. Logistics, procurement, and accounting files are prime candidates. 
Flight scheduling data should be among the first to be implemented. Since 
NASA will be playing a constantly expanding role in the environmental sciences 
through the Skylab and earth resources programs, most of the environmental 
data should be structured into the data base. 

® Data Item Dictionary . The data item dictionary should have a complete listing 
of the content and organization of all data items in the MSC data base. There 
should also be functional area data dictionaries which would contain only those 
data items relating to particular MSC activities. These smaller data diction- 
aries will be more meaningful and usable since they will contain only pertinent 
data items for specific MSC activities. 

® Data Source Document Index . In conjunction with the data item dictionary, a 
data source document index should be provided to describe all input transac- 
tions and other submittal forms used by MSC and contractors for entering data 
items into the data base. A description of each data source document and the 
data items created or updated in the data base by using that source document 
will be contained in the index. 
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4.1 MANAGEMENT INVOLVEMENT 

In a major systems endeavor, it is imperative that management participate and involve 
themselves in its achievement and success. In organizations where the computer systems 
and the data base are regarded as major resources and as important tools in achieving 
goals, management must play a strong role. An automated system, to be an effective 
tool, requires a high degree of management involvement. 

The prime management functions of control, scheduling, and decision maldng must be 
applied by MSC management throughout the phases of system development, implemen- 
tation, and operation. 

4.2 MANPOWER REQUIREMENTS 

The manpower effort required to completely implement the DMS, structure the MSC appli- 
cation data into the data base, and train MSC personnel in utilizing the DMS and data base 
is shown in Figures 4-1, -2, and -3. 

The estimated implementation manpower figures indicate that approximately 336 man 
months would be required in a one-year time frame to provide the complete implementa- 
tion. The second and third years will require 144 man months and 108 man months, 
respectively, to maintain the data base, DMS, and terminal functions. These figures 
also include the adding of new MSC application data as well as enhancing the DMS func- 
tional capabilities. Detailed estimates of manpower and implementation schedules may 
be found in Section 4 of the Final Report. 

The manpower required to install and modify a currently operating DMS will be much less 
than that required to write and implement a newly designed DMS. There will also be man- 
power requirement differences depending on the capabilities provided in the acquired system 
and the language in which it is written. 

An effective DMS should allow MSC to reduce the number of application programmers and 
analysts required to support MSC’s effort. Through the use of a simple, user oriented 
terminal language, many program requests which normally would be routed to a con- 
tractor's programming group would now be done by a nontechnical person at a terminal. 
Thus, contractor manpower needs would be significantly reduced. 

As functional modules of the DMS become operational, MSC personnel in the applications 
areas being installed will have to be trained in the use of terminals and the terminal lan- 
guage. Computer operations personnel will also have to be trained in the operation of 
the DMS on the computer. 

4. 3 IMPLEMENTATION CONSIDERATIONS 

The most efficient approach in designing a DMS is to make it modular in nature. The DMS 
will basically consist of modules to define, create, and maintain the data base; sort and 
merge data; retrieve data; and generate reports. The DMS should be machine independent 
where possible, and it should be written in a language which is easily transferred to dif- 
ferent computer hardware. 
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Figure 4-1. Data Base Functions Implementation 
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Logic modules to handle the needs of the various applications such as earth resources, 
logistics, procurement, etc. , will be written separately but will utilize the capabilities 
of the DMS. These applications modules will be programmed and installed according to 
the applications priority list. Building a DMS in this fashion will reduce conversion costs 
and enable functional modules of the DMS to be used as they are installed and made oper- 
ational. It will also serve to test and check out the DMS under an operational type 
environment. 

Several benefits will accrue to MSC if a currently operational DMS is acquired and mod- 
ified to fit MSC's needs. Some systems are public domain, so it is quite probable that 
MSC could install one of these systems at a substantial lower cost and reduced time frame. 

A careful analysis of data must be made to determine which data is to be placed into the 
data base. The analysis of data should begin before any programming is done on the DMS. 
In fact, some data analysis was performed for the pilot study which will be beneficial for 
a larger data analysis to construct the Center-wide data base. 

A DMS requires an extensive user educational program. Users must be trained in the 
use of the DMS language, terminal language, terminal operations, data item dictionary, 
source data document index, DMS computer operations, and DMS batch operations. Users 
should receive the training they need to properly utilize the DMS as a tool to fulfill their 
job functions. Training manuals, classroom teaching, and private consultations with 
users must be provided. 
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SECTION 5 - SUMMARY/R.ECOMMENDATIONS 


During the course of the study, it became apparent that techniques must be implemented 
which would make information processing at MSC more responsive to the users’ require- 
ments. An effective solution to this problem is the implementation of a Data Management 
Supervisor (DMS), coupled with a comprehensive and well structured data base. 

One of the prime advantages that accrues from the use of a DMS is the increase of capa- 
bilities offered the user in solving his information problems. Other advantages are in the 
areas of improved programming techniques, certain cost reductions, and improved proces- 
sing efficiency. 

5.1 DATA MANAGEMENT SUPERVISOR (DMS) 

The advanced techniques of file management and retrieval made available by a DMS will be 
required by MSC to support the ever-increasing demand for information. 

Standardized program routines, such as report formatting, data editing, data retrieval, 
and updating, will provide a system more oriented toward enhancing responsiveness to 
many different t 3 ^pes of users. For the programming staff, ease and quickness of program 
maintenance and modification are significant factors . 

Through the earth orbital program and its related scientific applications, NASA will pro- 
duce more pertinent data on our emdronment, the movement of the earth land and ice 
masses, and various weather models than heretofore imagined. This massive volume of 
data will require techniques for its maintenance and worldwide dissemination superior to 
those currently utilized. 

Flight scheduling is one of the most active areas at MSC. It will become even more active 
during the Skylab and Space Shuttle programs. The data files required to handle flight 
scheduling are large. When changes to the flight schedules are made, rapid access to the 
data files is necessary. One minor change could cascade into many changes throughout the 
entire schedule. Real-time, direct access to the data is especially mandatorj^ while the 
missions are in progress. 

The earth resources area has the potential of becoming one of MSC's largest and most 
active areas. Millions of items of data will be structured into the earth resources data set 
in the data base. This data is available to the general public, and the demand by the public 
for this data will expand. Already, large educational institutions, research foundations, 
and industry have made requests for this data. 

All of these areas have a need for a DMS at the present time. This need will become even 
more critical as MSC efforts are phased out of the Apollo program into the Skylab program. 

Some MSC groups, such as earth resources, flight scheduling, and logistics, have an ur- 
gent need for a DMS. Though the need for a DMS is greater in some groups than in others, 
practically all of the groups who were interviewed or who attended the demonstrations ex- 
pressed a desire for MSC to install a DMS with a Center-wide data base. A few MSC groups 
even used the pilot DMS to do some of their production work. 
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A modular concept should be used in designing a DMS. Separate modules will be written 
to perform the various functions such as defining the data base, creating it, maintaining 
it, sorting data, retrieving data, and reporting data. Whenever changes to any area are 
required, a new module incorporating the changes can be implemented. 

A machine independent language for the DMS is an extremely desirable design feature. 

The major functional modules of the DMS should be written in a high level language such 
as COBOL. By doing this, a change in computers will require relatively minor modifi- 
cations to the DMS. 

5.2 PRACTICALLY STRUCTURED DATA BASE 

If is of critical importance that the data sets within the data base are uniquely structured 
to take full advantage of the capabilities provided by the DMS in meeting users' requirement. 

It would be unreasonable to assume that all data could be included in a data base since the 
capacity to store this volume of data would be unrealistic, and such a volume would down- 
grade the effectiveness of any system. It would also be unreasonable to assume that all of 
the data could be structured and stored in the same manner. Therefore, structuring of 
files must be versatile enough to accommodate the many different t 3 T>es of requirements. 

5.3 PROGRAMMING 

A powerful programming language will be provided by the DMS. This language will enable 
programmers to quickly design and implement complex application systems. 

The great advantage provided by the DMS is the vast library of specialized program module 
routines that can be utilized by the DMS programmer. These specialized functional mod- 
ules include routines such as file creation, file update, editing, encode/decode table look- 
up, statistical analysis, file sort and merge, data extraction, report formatting, report 
generation, graphics, etc. 

Most of the MSG applications can be designed and oriented to utilize the DMS terminal ca- 
pabilities. File maintenance and report generation can be quickly and easily performed 
utilizing a simple, user oriented terminal language provided by the DMS. This language, 
being specially designed for use by nontechnical persons, allows managers and staff as- 
sistants to rapidly update data and receive individually oriented, highly complex, and 
meaningful reports. 

Application program modifications and expansion can be made easily and quickly through 
the high level DMS programming language. The DMS programmer can invoke the DMS 
functional modules to perform the desired processing. The DMS programmer could also 
include and call up program routines that were written in other programming languages , 
such as COBOL. This capability allows utilization of existing MSG program modules and 
routines by specifying their name in a DMS program. The DMS also allows programmers 
to continue writing new application programs in other languages, such as COBOL. 

Many programs will be written at terminals using the DMS terminal language. Once these 
are checked out and are producing successful output, they will be stored in the system 
libraries. They can then be executed by simply calling up the program name. 

The DMS will generate program modules that have a common design format for the same 
DMS processing function. The design format will be highly advanced and produce efficient 
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processing routines. Thus for each specified DMS language processing function, the DMS 
programmer knows the program logic that will be generated to perform that function. 

The standardized program routines that will be generated by the DMS have many advan- 
tages. First, it allows each processing function to be designed to produce the most 
efficient processing. Second, it allows changes to be easilj' made to the generated pro- 
grams. It also provides for simple, standardized documentation, since the same proces- 
sing function would always generate basically the same program design logic. It also 
facilitates making modifications or expansions to programs written by another programmer. 

5.4 USER BENEFITS 

The design and construction of the data base will aid the various MSG groups in increased 
communications and coordinated activities. Proprietar 3 '^ rights to a group's data will vir- 
tually disappear unless the data requires securitj'^ protection. As a result, MSG personnel 
will graduallj'^ think more of Genter-wide needs and activities rather than group needs and 
activities. 

The expanded capabilities can be categorized into three broad areas: real-time processing, 
control of applications and data, and more efficient utilization of hardware and software. 

Real-time processing provides a multitude of expanded capabilities, the most important 
being the man/machine interaction via a remote or local terminal. MSG management will 
have immediate access to data concerning MSG activities and increased visibility of the 
many MSG efforts and activities. 

Data access security protection will be one of the first DMS functional capabilities imple- 
mented. This will ensure that data security protection will be provided before any func- 
tional portions of the DMS are released for utilization. 

The automatic scheduling of production applications is another significant capability pro- 
vided. The operational schedule of execution could be specified to the DMS and special 
override conditions provided. This capability will be of considerable assistance to com- 
puter operations in the scheduling of weekty, monthty, and year-end runs. 

5.5 GOST 

Greather throughput per computer dollar will result from the installation of a DRIS. The 
many data structuring techniques provided by the DMS will reduce the amount of time to 
retrieve data, thus allowing computer applications to be processed much more rapidly. 
Reduced processing time means reduced costs. It is difficult to estimate the dollars 
saved by providing real-time access to data. In the past, managers have had to wait 12 
to 24 hours for computer run results. The activities of many people were curtailed or 
greatly hindered by the wait. This is especially true of programmers who have to wait 
for turnaround on program tests. 

Gosts will be greatly reduced through utilization of the simplified high level programming 
capabilities provided by the system and the standard procedures for computer operations 
for all phases of the DMS activities. 

The key to reduced program maintenance costs is the ease of modifications that can be 
made at two different program levels. At the highest level, using the DMS programming 
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language, program mcdifications and expansion can be easily implemented. At another 
program level, using the standardized logic modules generated by the DMS, program 
maintenance is also facilitated. This results largely from the fact that the basic logic 
design format would be known for each of the generated MSC applications functions; e.g. , 
soi’ting, report generation, etc. Also important is having the generated application pro- 
grams v/ritten in a high level language, such as COBOL. Tlie high level language facili- 
tates program modifications and expansion at the application program level. 

An MSC application module (e.g. , logistics, procurement, etc.) will be developed and im- 
plemented in a much shorter time. The cost savings to MSC is therefore not only in the 
reduced amount of application program design, implementation, and maintenance, but also 
in the reduced lead time required for new application implementation. 

MSC has an enormous number of application data files which require file maintenance pro- 
grams to keep the data current and valid. A tremendous file maintenance cost savings will 
be achieved for MSC through utilization of the DMS programming languages. The size of 
the data files and the number of the application data files will also be reduced. 

There will be an initial cost for implementation of the DMS, data base, hardware configu- 
rations, and training. This cost will be minimized by the long-range savings provided 
when the DMS is functionall 3 ^ operational. The additional data processing capabilities pro- 
vided by the DMS will also offset the initial cost. 

5.6 SUMMARY 

In summary, it is recommended that NASA MSC: 

e Implement a Data Management Supervisor (DMS) that either embodies the re- 
quired capabilities as set forth in this study or may easily be enhanced to in- 
clude the required capabilities. 

© Establish an applications /data file priority list for implementation that is com- 
patible with lead times of known MSC missions. 

e Immediately start analj'^zing and structuring data sets which realistically re- 
flect MSC requirements. 

e • Develop a Center-wide data element and function dictionary which would be used 
as a management tool to control system quality and as a user tool to obtain max- 
imum responsiveness. 

© Approve and implement acquisition of long lead hardware required to support 
the DMS and data base. 

9 Develop an MSC -wide management plan that will have the effect of recognizing 
the data base as an on-going MSC resource and thereby delegate its control to 
team management decisions rather than individuals and unilateral actions. 

o Select a contractor thoroughly familiar with commercial-type processing, all 
aspects of DMS logic, and complex and varied data base construction to imple- 
ment the MSC DMS. Contractor familiarity and understanding of user require- 
ments are essential factors to be considered. 
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